Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/d20/welcome.arc/BB_PROCD.101

Text File | 1991-06-09 | 23.5 KB | 550 lines

          ZONE ONE BACKBONE OPERATION PROCEDURES


Revision: 1.01                    Effective Date: May 1, 1991


PROLOGUE

This document sets forth procedures followed by the Zone One
Backbone Echomail System.


If any item in this document are in conflict with any existing
or subsequent General Fidonet Policy, then General Fidonet
Policy will be in effect.

This document addresses echomail at the zone level.  It is not a
General Echomail Policy.  This document makes no attempt to
address any issues below the "Backbone Level".


I.  HISTORY

Echomail consists of the sharing of message bases or conferences
between various independent network addresses.  The echomail
concept started with a series of programs by Jeff Rush.  Since
the original implementation, many authors have written programs
improving on the original idea.  In spite of worries that the
flow of echomail would increase netmail traffic to the point
that the network would collapse under its own weight, echomail
has been a success.

To simplify the distribution of echomail at the zone level, the
Backbone was formed.  As a result of the growth of Fidonet and
the increase in the volume of echomail, it has become necessary
to set forth operational procedures to allow the general Fidonet
sysop to know what services he can expect from the Backbone.


II.  DEFINITIONS

1.  GENERAL FIDONET POLICY:  The document which governs Fidonet
as adopted by Fidonet.  The document as of this writing is
Policy 4 and is subject to change.

2.  NODE:  A Fidonet member, as per General Fidonet Policy.

3.  ECHOMAIL:  A form of mail in which message bases are shared
between independent systems with unique Net/Node addresses.

4.  ECHOMAIL CONFERENCES:  An echomail conference is a message
base or forum, distributed under a specified echomail conference
name, dealing with a defined area of interest.  Echomail
conferences are hereafter referred to simply as conferences.
Examples include COMM, an inter-zone telecommunications
conference, and POLITICS, a zone level political conference.

5.  ZONE ECHOMAIL COORDINATOR:  This individual is responsible
for coordination of echomail at the zone level.  The Zone
Echomail Coordinator is hereafter referred to simply as the ZEC.

6.  REGION ECHOMAIL COORDINATOR:  This individual is responsible
for coordination of echomail at the region level.  The Region
Echomail Coordinator is hereafter referred to simply as the REC.

7.  NET ECHOMAIL COORDINATOR:  This individual is responsible
for coordination of echomail at the net level.  The Net Echomail
Coordinator is hereafter referred to simply as the NEC.

8.  ECHOMAIL HUBS:  These are nodes who distribute echomail.
The Echomail Hubs are hereafter referred to simply as Hubs.  The
Zone Hubs distribute echomail at the zone level.  The Region
Hubs distribute echomail at the region level.  The Net Hubs
distribute echomail at the net level.

9.  CONFERENCE MODERATORS:  These individuals preside over
conferences.  Conference Moderators are hereafter referred to
simply as Moderators.

10.  RESTRICTED DISTRIBUTION CONFERENCE:  A restricted
distribution conference is one which is restricted only to
eligible recipients.  Examples include MODERATOR, a pre-register
conference for Moderators, and MEADOW, a conference for Opus
Sysops.

11.  ZONE ONE ECHOMAIL BACKBONE:  The Zone One Echomail Backbone
consists of Zone Hubs (commonly referred to as "Stars") and the
Regional Hubs (who directly connect to the "Stars").  The Zone
One Echomail Backbone is hereafter referred to simply as the
Backbone.

12.  ZONE ONE ECHOMAIL CONFERENCE LIST:  The Zone One Echomail
Conference List identifies the registered zone level
conferences.  The Zone One Echomail Conference List is hereafter
referred to simply as the Echolist.

13.  ZONE ONE ECHOMAIL CONFERENCE LIST COORDINATOR:  This
individual is responsible for the Zone One Echomail Conference
List.  The Zone One Echomail Conference List Coordinator is
hereafter referred to simply as the Zone Echolist Coordinator.

14.  ECHOMAIL GATEWAYS:  These are nodes whose systems are used
to exchange mail with other groups.  The term Echomail Gateway,
as used hereafter, shall include all forms of gating, including,
but not limited to, zone-gating, inter-network gating, and
domain-gating.

15. VOTE:  Any vote shall be carried out in a fair and decent
manner.  A good faith attempt shall be made to make all eligible
voters aware that a vote is about to occur and to make available
all necessary information.  At a minimum, this notice shall be
posted in the REC conference 7 days prior to the start of the
voting period.  The voting period shall be 7 days.

16.  ABSOLUTE MAJORITY:  The term absolute majority means more
than 50 percent of those eligible to vote.


III.  DUTIES OF ZONE ECHOMAIL COORDINATOR, ZONE HUBS, ZONE
ECHOLIST COORDINATOR, REGIONAL COORDINATORS AND MODERATORS

1.  DUTIES OF ZONE ECHOMAIL COORDINATOR:  The ZEC shall
coordinate echomail distribution at the zone level.  This
includes coordinating the transmission and routing of echomail
so that it is done in a manner so as to avoid creation of
duplicate messages within a conference.

The ZEC shall make available, to any region, any conference
which that region is eligible to receive.  If for any reason the
ZEC does not have access via recognized distribution channels to
a specific conference, he can not be expected to provide it.

An exception is that the ZEC is not required to make available
any conference which routinely contains messages which are
encrypted or illegal.

Nothing in this provision requires that a ZEC or Zone Hub must
import any conference to the extent of adverse economic impact.

The ZEC shall recognize conferences at the zone level.  The ZEC
shall maintain a list of available conferences at the zone level
as well as the requirements of each conference as supplied by
the Moderator (Echolist).

The ZEC shall appoint Zone Hubs (Stars) to distribute echomail
at the zone level.  The ZEC may also serve as a Zone Hub, but is
not required to do so.

The ZEC shall make available a minimum of one connection to each
"Star", to each region.  Each Region is not required to use all
available connections, but it is the ZEC's responsibility to
insure that the connections are available.

2.  DUTIES OF ZONE HUBS:  All systems designated as Zone Hubs
(Stars) by the ZEC will be required to allow a single direct
connection from each region as requested by the REC of each
region.  Zone Hubs may act as Regional Hubs and/or File
Distribution systems only if such actions do not interfere with
the primary duties of Zone Echomail Distribution.  Zone Hubs
will make any conference available that has been designated a
"Backbone Conference" by the ZEC.  Zone Hubs will distribute a
text file named "FIDONET.NA" that is a list of all Conferences
available from the Zone Hubs.

3.  DUTIES OF ZONE ECHOLIST COORDINATOR:  The Zone Echolist
Coordinator shall compile and make available the Echolist.  This
is a registry of zone level and inter-zone conferences, updated
monthly, and optionally, conferences at various other levels.

The content and format of the Echolist will be at the sole
discretion of the Zone Echolist Coordinator, except that it
shall include the conference name, the Moderator's name, a
netmail address listed in a publicly available nodelist of any
network where the Moderator may be reached, a general
description of the conference topic, eligibility requirements
for restricted conferences, network of origin for conferences
which originate outside of Fidonet, distribution plan if other
than via the Backbone, and rules for each conference.

4.  DUTIES OF REGIONAL ECHOMAIL COORDINATORS:  This Document
details the REC's duties in relationship to the Backbone, only.
The REC shall coordinate echomail distribution at the regional
level.  This includes coordinating the transmission and routing
of echomail so that it is done in a manner so as to avoid
creation of duplicate messages within a conference.

The REC shall make available, to any net, any conference which
that net is eligible to receive.  If for any reason the REC does
not have access via recognized distribution channels to a
specific conference, he can not be expected to provide it.

An exception is that the REC is not required to make available
any conference which routinely contains messages which are
encrypted or illegal.

Nothing in this provision requires that a REC or Regional Hub
must import any conference to the extent of adverse economic
impact.

The REC shall appoint Regional Hubs to distribute echomail at
the regional level.  The REC may also serve as a Regional Hub,
but is not required to do so.  The REC designates the systems
that will have the direct connections to the Zone Hubs.  In the
event the REC feels his region needs more than one connection
per Zone Hub, he may request an additional connection.  Any such
connection will be granted on a space available basis.  Each
such request will be looked at on a case-by-case basis.

5.  DUTIES OF MODERATORS:  Moderators shall make, in good faith,
every reasonable effort to insure that their conferences do not
distribute or promote illegal activities or information as
defined in Section V, Paragraph 2.

Moderators shall publish the conference rules in their
conferences at least once a month.

Moderators shall be responsible for seeing that messages
contained in their conferences correspond to the conference's
theme.

Moderators shall not fail to perform their duties for a period
of more than 10 days without failing to designate proxies.

Moderators are encouraged to appoint Co-Moderators to assist
them in their duties.  If the Moderator is not a member of
Fidonet, he must list an address in a publicly available
nodelist of any network, that he may be contacted if the need
arises.

Moderators shall report any violations of these procedures to
the proper Echomail Coordinators and lodge any appropriate
policy complaints as provided for in General Fidonet Policy.

If a Moderator believes that a Node is violating a conference
rule, he may authorize the feed to that Node be severed.  This
authorization shall be made in direct written form (netmail), to
the Hub feeding the offending Node, with a copy to the offending
Node.


IV.  SELECTION OF ZONE ECHOMAIL COORDINATOR, ZONE ECHOLIST
COORDINATOR AND MODERATORS

1.  GRANDFATHER CLAUSE:  The ZEC, Zone Echolist Coordinator and
Moderators currently holding these positions as of the date of
acceptance of this document shall continue to serve in said
capacity.

For the purpose of calculating the term of office, such term
will be deemed to have started on the date that this document
goes into effect.

2.  SELECTION OF THE ZONE ECHOMAIL COORDINATOR:  The ZEC shall
serve for a term of 1 year.  He shall be elected as follows:

    A) Upon resignation or replacement of the existing ZEC, the
    Zone Coordinator (ZC) shall oversee the election of the new
    ZEC.

    B) After the nominees are selected, an election shall be
    held.  The ZEC will be elected by a absolute majority of the
    RECs.

The current ZEC can be identified from the 1/200 listing in the
Nodelist.

3.  REMOVAL OF THE ZEC:  The ZEC may be removed from his
position by a absolute majority of the RECs.  The ZC will
oversee the recall election in the same manner as prescribed for
electing the ZEC.

The ZEC may only be subject to recall for failure to properly
carry out his duties described above, or if he is no longer a
member of Fidonet.  A promise of "free" echomail delivery from
another source is not considered an acceptable reason for
recall.

A ZEC may be removed by the ZC for continued violations of
policy or for gross misconduct.

4.  SELECTION OF THE ZONE ECHOLIST COORDINATOR:  The ZEC shall
appoint the Zone Echolist Coordinator.

The current Zone Echolist Coordinator can be identified from the
1/201 listing in the Nodelist.

5.  SELECTION OF A MODERATOR:  A Moderator shall be selected as
follows:

    A) Upon formation of a conference, the person who forms the
    conference is the Moderator.

    B) Upon resignation or replacement of an existing Moderator,
    the conference's rules shall define how the new Moderator is
    selected.

A Moderator need not be either a sysop, or a member of Fidonet.
A Moderator must have an netmail address in a publicly available
nodelist where netmail concerning the conference may be sent.


V.  STATEMENT OF POLICIES

1.  BASIC ECHOMAIL POLICY:  The basic policy of echomail is to
promote communication in conferences in a lawful, friendly
manner consistent with the general principles of Fidonet.

2.  PROHIBITION ON ILLEGAL ACTIVITIES:  Knowingly distributing,
or allowing to be entered into conferences, any messages
containing or promoting illegal activities or information, is a
serious violation of this document.  As used in this paragraph,
"illegal activities" includes activities which are a violation
of civil law as well as activities which would result in
criminal prosecution.

3.  CENSORSHIP:  Removing a message from a conference, or
altering its contents, in the passing or distribution of
echomail, is considered a serious violation of this document.

An exception to this provision is the deletion of messages, by
any Node, which may lead to legal action against that Node.
Textual changes to such messages are not allowed.

An additional exception to this provision is the deletion of
messages, by any Node, which do not meet the echomail message
standards in Section V, Paragraph 13.  Textual changes to such
messages are not allowed.

Under no circumstances shall echomail be modified in any manner
which could potentially cause duplicates.

4.  COUNTERFEIT MESSAGES:  Entering or knowingly distributing
counterfeit messages is a serious violation of this document.  A
counterfeit message is defined as any message entered using
another person's name, handle or Node address with the intent of
deceiving others about the true author of the message.  No
handles shall be used to enter messages to knowingly provoke,
inflame, or upset participants in a conference with the purpose
of deceiving others about the true identity of the author.

5.  CHARGING FOR DISTRIBUTION:  Any entity which makes a profit
from the passing or distribution of echomail shall be deemed to
be excessively annoying and in violation of General Fidonet
Policy.  Profit is defined as the charging for echomail
distribution in excess of the actual cost to obtain and
distribute the echomail over a sustained period.  The cost of
the equipment used to obtain and distribute echomail may only be
recovered on a strictly voluntary basis.  Nodes who charge users
for access to their BBSs shall not be in violation of this
paragraph.

6.  RESTRICTED DISTRIBUTION CONFERENCES:  Participating Nodes
shall honor and support the restrictions placed upon restricted
distribution conferences.  Violation of this restriction by
individual Nodes is a violation of this document and shall
result in suspension of that Node from the violated echo in
accordance with Section III.

A violation of the restrictions placed on a restricted
distribution conference will be a violation of this document
only if the Moderator has posted the restrictions governing the
conference both in the conference and in the Echolist.

7.  PATHLINE OPTION:  The PATHline (as defined in FTS-0004), is
recommended for all Nodes, but is required for any node directly
connected to a Zone Hub (Star).

8.  SEEN-BY LINE:  Under the current technology and topology
(the routing structure of echomail), SEEN-BY lines play an
important part in reducing duplicate messages.  Tiny SEEN-BYs
will not be allowed until the ZEC feels that the topology allows
their use.  The stripping of SEEN-BYs (except by Echomail
Gateways) is not allowed unless approved by the ZEC.  Echomail
Gateways shall strip the SEEN-BYs of the exporting group to
reduce addressing conflicts.

9.  ECHOMAIL SOFTWARE:  using echomail software which does not
conform to the minimum acceptable standards as defined by the
Fidonet Technical Standards Committee (FTSC), and by this
Section, is a violation of this document.

10.  INTER-NETWORK CONFERENCES:  It is the general policy of
Fidonet to encourage the development of Inter-Network
Conferences.  Inter-Network Conferences shall conform to General
Fidonet Policy, as well as the provisions of this document, in
addition to any foreign network's provisions.

It shall be the duty of those providing the Inter-Network
Conference links to remove foreign network distribution
identifiers which will adversely effect the distribution of the
conference while in Fidonet.  The Inter-Network Conference links
maintained in Fidonet shall be operated such that they do not
interfere with the foreign network's distribution of echomail.

Conferences which originate outside of Fidonet must be
designated as such in the Echolist.

Echomail Gateways must be able to pass netmail through the
Gateway into the other network, unless it is technically
impossible to do so.

12.  ADDING OR REMOVING CONFERENCES FROM THE BACKBONE:  A
conference may be added to the Backbone only at the request of
the Moderator.  A conference must have a Moderator, be listed in
the Echolist, and its addition requested by two or more RECs,
before it is added to the Backbone by the ZEC.

The Moderator may, at his discretion, request that his
conference be removed from the Backbone.  The ZEC shall honor
such requests.

A conference will be removed from the Backbone when fewer than 2
RECs carry it.

The ZEC may also remove a conference from the Backbone due to
lack of traffic (under 10 messages over a two month period).

A conference is subject to removal from the Backbone when the
Moderator fails to properly carry out his duties, as described
as described in Section III, or violates Section V.

A conference is subject to removal from the Backbone if its
listing in the Echolist is not current.

    NOTE:  To allow time for all existing Backbone conferences
    to be listed in the Echolist, no such conference will be
    removed from the Backbone for a grace period of 120 days
    from the issuance of this document.

13.  ECHOMAIL MESSAGE STANDARDS:  Until the adoption of a
superseding standard by the Fidonet Technical Standards
Committee, the following echomail message standards are
recommended:

    A) Eight-bit characters (ASCII 128-255) and non-printing
    low-order codes (ASCII 2-31) are prohibited, except the use
    of 8Dh(soft <CR> character) per FTS-0004.  This is not
    intended to discourage participation of foreign zones or
    networks, which may permit said characters.  Any echomail
    processor should pass information exactly as it was
    received, without stripping any non-standard characters.

    B) There should be only one tear line in a message.  Tear
    lines should be limited to 25 characters including the
    required "--- " lead-in.  Tear lines should only contain
    packer or editor program identification.  Tear lines for
    message editors are discouraged.  If an editor adds a tear
    line, it should also add an origin line, to avoid multiple
    tear lines.

    C) There should be only one origin line in a message, except
    as noted in the next paragraph.  Origin lines should be
    limited to 79 characters including the required " * Origin:
    " lead-in and ending of a proper network address (i.e.
    Zone:Net/Node.Point with zone and point being optional),
    enclosed in parenthesis.

    D) "Extra" origin lines are allowed when a message is gated.
    The original origin line's lead-in should be changed to " #
    Origin:  ", and the Echomail Gateway's origin line added.
    There may be more than one extra origin line in the case
    that a message passes through multiple Echomail Gateways.
    The Echomail Gateway's origin line is limited to essential
    information only.  This consists of the required lead-in,
    the network name, "Gateway", a proper Fidonet address (i.e.
    Zone:Net/Node with zone being optional), enclosed in
    parenthesis.  Example:  " * Origin:  TComm Gateway
    (1:372/666)".

    E) SEEN-BY addresses should be in sorted order.  AKA's are
    not allowed in SEEN-BY lines unless you have more than one
    address which processes mail.  Or for one month during
    change of an existing address (to avoid duplicates to the
    previous address).  Node 0 addresses should not be used for
    echomail distribution.

    F) All current FTSC specifications must be followed.

14.  NETMAIL ROUTING:  It is important that users have access to
routed netmail in order to facilitate private replies to
echomail messages.  This helps reduce overall echomail message
volume by allowing off-topic replies, flames and other types of
messages which don't belong in the conference, to be sent via
routed netmail.

Until such time as a new General Fidonet Policy is adopted which
defines and codifies the routed netmail scheme, the following
shall be in effect:

    A) Zone Hubs and Regional Hubs shall accept routed netmail
    from any Node or Hub who exchanges Backbone conferences with
    them.  Routed netmail may be routed along echomail paths, or
    to a ZC, RC, or NC  who has agreed to handle such mail.  Any
    netmail message with a valid Fidonet destination will be
    accepted.  Refusal of netmail based a non-Fidonet origin
    will not be allowed.

    B) At the present time, routed netmail is provided by both
    the Coordinator and Echo Coordinator structures.  The ZEC
    shall cooperate with the Coordinators and the Echo
    Coordinators in further developing and maintaining a routed
    netmail scheme.

16.  FEEDING SEVERED NODE:  Knowingly feeding a conference to a
Node who has been severed for violations of this document or at
the request of the Moderator, where such feed is intended to
subvert either the provisions of this document or the authority
of the moderator, is considered a serious violation of this
document.


VI.  ENFORCEMENT

Enforcement of this document shall be under the provisions of
General Fidonet Policy.  Serious violations of these procedures
shall be considered excessively annoying under General Fidonet
Policy.

Complaints concerning violations defined under these procedures
may be filed by the aggrieved individual, the Moderator or by
any level of Echomail Coordinator to the appropriate IC, ZC, RC
or NC level.  All complaints made pursuant to this document must
be made within 60 days of the date of occurrence or discovery.
Complaints shall be filed under the provisions of General
Fidonet Policy, with a copy to the ZEC or respective REC, as
appropriate.

Enforcement of these procedures are immediate, with any
currently existing software allowed 90 days to conform (from the
date this document goes into effect).  30 day extensions may be
granted solely at the discretion of the ZEC if efforts to bring
about compliance are clear.  Continued use of aberrant software
after this period is a serious violation of this document.


VII.  CHANGES

Future changes to these procedures may be proposed by any Node,
by submitting the proposal to any REC.  The REC will then
determine if the proposal should be brought before the rest of
the RECs.  If two RECs concur with the proposed change, the
change must be brought to a vote of all RECs.

A absolute majority vote of the RECs is required in order for a
change to be implemented.